Intelligent communications networks

ABSTRACT

A service node is used in an intelligent communications network for providing services for customers. The node includes a server arranged to define a plurality of services; a plurality of resources each arranged to generate speech announcements in response to receipt of respective command signals and to provide an announcement finished signal when each generated speech announcement has finished being generated; a switch arranged to connect the resources to incoming calls routed by the network to the service node; and a controller arranged to respond to such incoming calls to place details of the calls in corresponding service queues, to receive from the server (a) a reserve resource request signal for reservation of a resource in respect of a call whose details have been passed to the server by the controller from the top of a service queue, thereby associating the call with the server, and in response to reserve a free one of the resources, (b) a connection request signal from the reserved resource to be connected to the call and in response to control the switch accordingly, (c) a command signal for the reserved resource to generate a corresponding speech announcement and in response to send the command signal to the reserved resource, (d) a signal for disassociating the server from the call and in response to store the current details of the call, (e) a signal indicating that the service defining means is ready to handle another call and in response to pass to the server the call then at the top of that service queue, and to receive from a reserved resource an announcement-finished signal, and in response to update the details of the corresponding call and to pass the updated details from store to the bottom of the corresponding service queue.

RELATED APPLICATION

This is a National Stage Application of PCT/GB95/01851 filed Aug. 4,1995.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to a method of and a service node for providingservices in an intelligent communications network.

2. Related Art

Before the advent of the stored program controlled (SPC) exchange, thePublic Switched Telephone Network (PSTN) comprised electromechanicalexchanges, such as Strowger and Crossbar exchanges, and electronicexchanges, such as TXE2 and TXE4 exchanges. However, even the mostadvanced of these types was only capable of performing a limited numberof functions over and above merely switching a call, i.e. making aconnection between an incoming channel or line and an outgoing channel.Furthermore, such additional functions were limited to operations forimproving the performance of the network, for example, repeat attempt atreaching a destination number via an alternative outgoing route in theevent that the first-choice route is busy.

SPC exchanges enabled customers to control various supplementaryservices via signals entered on their telephone keypad using the * and #buttons. However, the introduction of a new service, or the modificationof an existing service, meant that the control program had to be updatedin each of the SPC exchanges.

The current concept of an intelligent communications network is based ona core of interconnected Digital Main Switching Units (DMSU's), withlocal exchanges connected to the DMSU's (usually with each localexchange connected to two DMSU's for network resilience in the event ofan DMSU failure), and with services being provided and controlled bydiscrete service nodes at various positions in the network.

Each service node is connected to an DMSU of the network, whichrecognises service access digits dialled by a customer and routes thecall to the service node for the provision of the requested service forthe customer.

As an example of the abovementioned concept, an Intelligent Networktestbed architecture is disclosed in the article “Experiences inPrototyping the Intelligent Network”, by Peter O'Reilly, Hing Fai(Louis) Chong, Russell Sivey and Lawrence Lattanzi; IEEE GlobalTelecommunications Conference, Nov. 29 to Dec. 2, 1993; Volume 1 of 4,pages 1923 to 1930. In this architecture, a Service Control Point (SCP)is connected by a signalling link, known to telecommunications engineersas a C7 or SS7 link, to a switch. The SCP is also connected by a datalink for call control commands and messages to an intelligent peripheral(IP) containing resources, such as announcements and digit collection.The IP is connected to the switch by a communications link providing avoice path.

The article “Service Script Interpreter, An Advanced Intelligent NetworkPlatform” by Paul van Hal, Jan van der Meer and Nael Salah, published inEricsson Review No. 1, 1990, pages 12 to 22, describes various networkelements of Ericsson's Intelligent Network Architecture. One of theseelements is an Intelligent Peripheral (IP) which is a collection ofversatile and cost-effective equipment allowing communications betweenthe Intelligent Network and its subscribers. The IP can send a number ofdifferent announcements to subscribers and receive digits from dual tonemulti-frequency (DTMF) telephones, the announcements being either of afixed format or having a variable part. The IP can be provided as aseparate node accessible by several Service Switching Points (SSPs)through which it is controlled by commands from respective ServiceControl Points. Digits received by the IP are sent to the controllingSCP, through the associated SSP, for analysis.

In International Application Number PCT/US91/03086 (Publication NumberWO 91/17616) a disk system stores voice message segments (VMS), each VMShaving an identifying address number. When voice messages are to beplayed to subscribers, Send Message commands are sent via a voicemessage management module (VMMM) to an input/output processor whichrefers to a look-up table, by which it converts the Message Number to arespective sequence of VMSs, and retrieves the sequence of VMSs from thedisk system. The VMM then sends corresponding commands, including fieldsdesignating the Channel Number, Call ID and Message Number of themessage to be sent, into a command queue of a buffering interface modulewhich receives the respective sequences of VMSs and inserts them intothe required channel of a multiplexed transmission link to the switch.

In the article “SCP Development in a multi-processor UNIX environment”by S. Hollywood, Proc Int Council for Computer Communications, May 4-6,1992, Tampa, pages 278-287, when an application passes a request to theService Logic Execution Environment (SLEE) for, e.g., playing anannouncement, it passes not only the request but the current call statusor call context data. When the external request completes, the SLEE cansend the resulting message and the call context data to any availableapplication process for that service, since the package of data containsall the information for the call

SUMMARY OF THE INVENTION

According to a first aspect of the present invention there is provided aservice node for use in an intelligent communications network forproviding services for customers, comprising:

service defining means arranged to define a plurality of services; aresource arranged to generate speech announcements in response toreceipt of respective command signals;

a switch arranged to connect the resource to incoming calls routed bythe network to the service node; and

controlling means arranged to respond to such incoming calls to placedetails of

the calls in corresponding service queues,

the node being characterised in that:

there are a plurality of said resources, each having a respectiveidentity and each being arranged to respond to receipt of anannouncement command by delivering a corresponding speech announcementover a respective speech path to the switch; and

the controlling means is further arranged

(a) to respond to receipt of a reserve resource request signal from theservice defining means for reservation of a resource in respect of acall whose details have been passed to the service defining means by thecontrolling means from the top of a service queue, thereby associatingthe call with the service defining means, by selecting one of theresources whose status is free, changing its status to in use, andincluding the identity of the selected resource in the details of thecall,

(b) to respond to receipt of a connection request signal from theservice defining means for the selected resource to be connected to thecall by sending to the switch a connection command to connect the callto the respective speech path for the selected resource,

(c) to respond to receipt from the service defining means of a commandsignal for the generation of a corresponding speech announcement and inresponse to send the command signal to the selected resource,

(d) to respond to receipt from the service defining means of a signalfor disassociating the service defining means from the call by storingthe then current details of the call,

(e) to respond to receipt from the service defining means of a signalindicating that the service defining means is ready to handle anothercall by passing to the service defining means the call details then atthe top of that service queue, and

(f) to respond to receipt from a resource of an announcement finishedsignal by updating the stored details of the corresponding call andpassing the updated details from store to the bottom of thecorresponding service queue.

Such a construction of service node enables efficient operation with theservice defining means able to request a function without being involvedin the management of that function, and the controlling means beingresponsible for selecting and relaying commands to a resource.Furthermore, because the identity of the selected resource is includedin the call details upon its initial selection, this resource willremain reserved and associated with that call until the service definingmeans decides that the call is ended or that there is no furtherannouncement to be sent to the customer.

Preferably, the controlling means comprises a common resource handlerhaving a first part arranged to respond to receipt of the reserveresource request signal to perform the selection of the free resourceand the provision of its identity for inclusion in the call details, andarranged to provide for the service defining means a resource reservedsignal upon completion of the reservation of the free resource.

Preferably, the common resource handler also has a second part arrangedto respond to receipt of the announcement command signal by selectingfrom a plurality of dialogue identities a dialogue identity having afree status, changing its status to in use, providing the selecteddialogue identity to be included in the details of the call inassociation with the selected resource identity, and sending theannouncement command in association with the selected dialogue identityto the selected resource.

According to a second aspect of the present invention there is provideda method of operating a service node in an intelligent communicationsnetwork for providing services for customers, comprising the steps of:

receiving at a switch of the service node a call routed to the servicenode by the network, identifying the requested service and placingdetails of the call in a corresponding service queue;

passing the call details, when at the top of the service queue, to aservice defining means of the service node when it is next ready toprocess a call;

selecting a free one of a plurality of resources of the service node,each being arranged to respond to receipt of an announcement command bydelivering a corresponding speech announcement over a respective speechpath to the switch;

changing the status of the selected resource from free to in use, andincluding the identity of the selected resource in the call details;

connecting the selected resource to the incoming call by the switch inresponse to a command from the service defining means;

generating by the selected resource a speech announcement correspondingto an announcement command from the service defining means;

storing the call details current at the time of commanding the selectedresource and releasing the service defining means to process anothercall;

generating by the selected resource an announcement finished signal andin response updating the stored call details;

placing the updated call details at the bottom of the correspondingservice queue; and maintaining the in use status of the selectedresource until the call is terminated or the service defining meansdetermines that the selected resource is no longer required.

Preferably, the selection of the free resource and the provision of itsidentity for inclusion in the call details are performed by a first partof a common resource handler of the controlling means, and including thestep of providing by said first part a resource reserved signal for theservice defining means upon completion of the reservation of the freeresource.

Preferably, there are included the steps of selecting from a pluralityof dialogue identities, by means of a second part of the common resourcehandler in response to receipt of the announcement command, a dialogueidentity having a free status, changing its status to in use, providingthe selected dialogue identity to be included in the details of the callin association with the selected resource identity, and sending theannouncement command in association with the selected dialogue identityto the selected resource.

BRIEF DESCRIPTION OF THE DRAWINGS

A specific embodiment of a service node in accordance with the presentinvention will now be described by way of example with reference to thedrawings in which:

FIG. 1 is a schematic diagram of a Service Logic Execution Environmentof the service node;

FIG. 2 is a diagram showing the storage locations of a Call Instanceused in services provided by the service node;

FIG. 3 is a diagram showing the processing of a Call Event;

FIG. 4 is a diagram showing initialisation of the Call Instance;

FIG. 5 is a diagram showing the allocation of a resource to the CallInstance;

FIG. 6 is a diagram showing the connection of a speech path between theresource and a caller;

FIG. 7 is a diagram showing the command of the resource by anapplication;

FIG. 8 is a diagram showing the response of the resource;

FIG. 9 is a diagram showing the procedure when the application hasfinished;

FIG. 10 is a diagram showing the procedure when the call clears; and

FIG. 11 is a diagram showing the procedure when the resource clearsdown.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

As can be seen in FIG. 1, the major part of the service node of thepresent invention is the central control function which is designatedthe Service Logic Execution Environment (SLEE) 10 and which constitutesa controlling means of the present invention.

The SLEE 10 comprises a respective Application Programming Interface(API) process, 11 a to 11 n, for each of a plurality of ApplicationInstances (constituting service defining means of the presentinvention), 12 a to 12 n, in each of a plurality of Application Types,13 a to 13 n, a Call Model process 14, a Scheduler process 15, and ahandler process for each of a plurality of subsystems of the servicenode, namely SLEE Management System 16, Switch 17, Billing System 18, aplurality of Intelligent Peripheral (IP) Resources 19 having a commonhandler 19H, and a plurality of Conversation Resources 20 having acommon handler 20H.

In this specification the terms Intelligent Peripheral and Service Nodeare to be taken as having the same effective meaning, although, inpractice, a Service Node is constituted by an Intelligent Peripheraltogether with a switch 17.

In this embodiment, each of the IP Resources 19 is a speech applicationsplatform (SAP) containing its own digit collection means. In alternativeembodiments, there is a plurality of digit collection means which can bereserved and associated with a SAP as and when needed for servicesinvolving digit collection.

Each of the Conversation Resources 20 is a non-speech resource, i.e. aresource which is not connected to a port of the switch 17 and which isnot arranged to send or receive signals from the customer (MF signals orspeech). Examples of types of Conversation Resources 20 are personalidentification number (PIN) validation, protocol conversion for when theservice node needs to communicate with a remote resource or system, andmanagement logic for managing entries in database 28.

For convenience, the above processes will generally be referred to bythe process name, and each handler will be identified as 16H, 17H, etc.Handler 19H has an internal part 19Hint which interfaces signals betweenapplications and a Shared Memory 21 of the SLEE, and an external part19Hext which interfaces signals to and from the IP Resources 19.

Each of the component parts of the SLEE 10 is implemented as a UNIX (atrade mark of AT & T) process on a platform which need not be describedin detail but which is in the form of a multi-processor, multi-tasking,fault tolerant UNIX environment. Where appropriate, these processescomprise sub-processes for both-way communication of messages. Suchsub-processes are well known to the skilled person in the art and willnot be mentioned specifically, apart from Switch Message Handler 26,which constitutes a message receiving sub-process of the Switch Handler17H.

The component processes of the SLEE 10 communicate with each otherthrough a block of the Shared Memory 21 which they can all access. Thisarrangement of separate processes working in parallel greatly reducesthe likelihood of serious bottlenecks.

Application Instances are started up by the SLEE Management System 16 atthe initialisation of the SLEE 10 and each new call entering theplatform creates a new Call Instance 22 (FIG. 2) in the Shared Memory21.

Each Call Instance 22 holds data specific to a respective call, and thevarious categories of data shown in FIG. 2 are Mapped IP Resources,Mapped Conversations, Switch Dialogues, Clearing Flags, Context Memory,Charge Record, and API Events. Some of these categories have more thanone storage location in the Call Instance, e.g. IP Resource and APIEvents.

Each Application Type 13 can provide one or more defined services, anddifferent calls (possibly using different services) can all share anyone Application Instance 13 by being cut in and out as the applicationrequires. The Context Memory of a Call Instance 22 is used by anapplication to keep track of the state that a call is in.

Multiple Application Instances 12 of the same Application Type 13 areprovided in order that a number of calls using the same service can runin parallel. The Scheduler 15 of the SLEE 10 manages the allocation ofcalls to the Application Instances 12 so that call events can beprocessed.

As external events occur, the handlers queue them on their respectiveCall Instances 22. FIG. 3 shows the various steps by which these callevents are retrieved and sent to an application for processing.

The Scheduler 15 decides which service will be the next to run on thebasis of the relative priorities of each Service Instance 23. Thesepriorities are recalculated each time that the Scheduler 15 is activatedsuch as to ensure that whilst all services will run at some time, thosewith higher service priorities (which are set by the SLEE ManagementSystem 16) will run more often. The Service Instance with the highestrelative priority and with Executable Calls queued on it is chosen to berun (this step is referenced 30 to avoid overlap with other referencenumerals). The Scheduler 15 retrieves the service's owning ApplicationType (step 31) and adds the Service Instance 23 to the bottom of theService Queue 24 (step 32). A Blocking Semaphore in the Application Type13 is increased by the Scheduler 15 (step 33), signalling that anothercall is ready to be processed by one of the Application Instances 12belonging to this Application Type 13. When this happens, the nextService Instance 23 is moved off the queue 24 (step 34) and the nextCall Instance 22 is removed from its Executable Call Queue 25 (step 35).The first AP) Event belonging to this Call Instance 22 is sent togetherwith the call's Context Memory to the application to be processed (step36).

The application performs the tasks necessary to act upon this event, andupon completion of those application tasks it issues an API Suspendcommand and then an API Provide Instruction command, and modifies theContext Memory (step 37) to reflect the change of state of the call. AnyManagement Events queued for the application are issued to it (step 38)before the process blocks on its semaphore (step 39) ready for the nextcall event.

The application sends the API Suspend command to the SLEE 10 to release(dissociate) the Call instance 22 from the application, and sends theAPI Provide Instruction command to cause the application to becomeblocked ready for the next call.

There now follows a description of the processes which occur for atypical call scenario for a message recording service provided by theservice node. Whilst there are many difference tasks that can occur,every call using the platform proceeds in a similar way to the followingdescription.

Assume that a customer has subscribed to a network-based messagerecording service (hereinafter referred to as “voicemail service”), theplatform (not shown) for which includes a database for storing depositedspoken messages and is associated with an DMSU of the PSTN. When thecustomer has activated the voicemail service, calls to the customer areautomatically connected by the network to the platform and any desiredspoken messages (hereinafter referred to as “voicemail messages”) arerecorded for later retrieval by the customer, and the voicemail platformwill send information about the voicemail messages (customer accountnumber, caller's name) to the application in the service node forstorage in the database 28, which increments the stored calls registerassociated with that account number and stores the name in associationwith an index representing the current position of that voicemailmessage in the voicemail platform database.

When the customer wishes to find out if he has any voicemail messageswaiting for him, he dials the service access digits for gaining accessto the voicemail service and the PSTN routes the call (regardless ofwhere it has originated on the network) to the service node.

Referring to FIG. 4, in which the steps are numbered starting from 11,when this call arrives at the service node the digits are passed via asignalling link from the switch 17 to the Call Model 14 which recognisesthe dialled service access digits for the voicemail service and, inresponse, creates and initialises a new Call Instance 22 (step 40)within the SLEE's Shared Memory 21 and maps the incoming call to itsfirst IP Resource, namely IP Resource 0 (step 41). The actual IPresource will be the incoming channel on which the incoming call appearsand it will be the identity of this channel that will be mapped to theIP Resource 0 location of the Call Instance 22. The Call Model 14initialises the call's Charge Record by recording the incoming call orevent with a time stamp (step 42) in the Charge Record location of theCall Instance 22. The SLEE 10 then puts an API Incoming Call event onthe call's API Events queue (step 43) and queues the Call Instance 22 asan Executable Call on the appropriate Service Instance 23 (step 44).

The Scheduler 15 is triggered and the call event processing phase isentered, as described with reference to FIG. 5.

Referring to FIG. 5, when the Scheduler 15 decides that it is time for acall to execute, the SLEE 10 sends to the Application 13 the APIIncoming Call Event from the Call Instance's API Events queue (step 45).The application receives this event, refers to a state table of events(not shown) and runs from the next following position, which in thiscase of a new call is from the beginning of the service.

The application will require the use of at least one IP Resource otherthan IP Resource 0. First, it must reserve a resource on a free one ofthe call's application-mapped IP Resources (e.g. Resource 3) by sendingan API Reserve Resource message to the SLEE 10 (step 46). Theapplication will itself select the free IP Resource in the Call Instance22 and ask the SLEE 10 to reserve a free resource and map its identityto the selected IP Resource. The SLEE's Internal API Resource Handler19Hint receives the message, finds a free (unused) resource of thecorrect type in the Free Resources store (Resource X) and maps it to thecall by moving the resource identity from Free Resources to the CallInstance's IP Resource 3 (step 47). In this step, the resource may beactually removed from Free Resources, or it may be effectively removedby setting a flag to mark that resource as in use and not free. Asuccess message is returned to the application as a return code (step48).

To make use of the resource the application must connect its speechchannel to that of the call as shown in FIG. 6. It does this by sendingan API Connect message (step 49) with reference to the two resources itwants to connect (i.e. IP Resource 0, the incoming call, and IP Resource3, the required resource).

The SLEE's API Switch Handler 17H receives the message, allocates(reserves) a free Switch Dialogue Id to the Call Instance 22 (step 50)and uses it to send a request for connection to the switch 17 (step 51).The switch 17 receives the request and connects the call to Resource X(step 52). It signals success back to a Switch Message Handler 26 of theSLEE 10 (step 53).

Having reserved a resource, the application now communicates with it,for example in this scenario it requests that the resource play arecorded announcement to the customer. It does this, as shown in FIG. 7,by sending an API IP Resource Command to the SLEE 10 with theannouncement type included (step 54). The SLEE's External API ResourceHandler 19Hext receives this message and sets up a dialogue with theresource by allocating an Id from the Free Dialogue Id's store to thecall's Application IP Resource (step 55). It then associates thisDialogue Id with the command and sends it to the mapped resource (step56).

Having sent such a command, the application will leave the resource togenerate the announcement and proceed to handle another call under thecontrol of the Scheduler 15. To do this, the application must suspendthe call by first sending an API Suspend command to the SLEE 10, andthen sending an API Provide Instruction command.

In this scenario, this first API Resource Command is for generating a“Welcome” announcement and for collecting twelve digits representing thecustomer's account number and personal identification number (PIN).

In FIG. 8, Resource X receives the application's command and startsgenerating the Welcome announcement, “Welcome to Voicemail. Please enteryour account number and PIN.” (step 57). Resource X is arranged toidentify digits received at any time after the start of the Welcomeannouncement, and to stop generating the announcement at the time thatthe first of these digits is received and recognised.

On receipt of the first digit, Resource X sends to the SLEE 10 an APIEvent message including the value of the first received digit. Thismessage is queued on the API Events section of the Call Instance 22. Forthe purposes of the present invention it is sufficient to state thatthis application requires the first digit to perform an initial part ofthe account number processing, and that not all applications involvingaccount numbers require the first digit for initial processing. Thedialogue between the application and the Resource X has not yetfinished, i.e. it remains open, so the Dialogue Id is permitted toremain associated with the Call Instance's IP Resource.

Normally, the customer will enter his eight digit account number and hisfour digit PIN within a timeout started at the beginning of theannouncement, and when twelve digits have been collected the Resource Xwill send to the SLEE 10 (step 58) a Digits Collected message containingthe digits, this message being associated with the same Dialogue Id aswas sent to the Resource X by the SLEE 10 with the command.

If the customer had failed to enter twelve digits before the timeout, orif for any other reason Resource X had not collected twelve recogniseddigits within the timeout, Resource X would have sent a CollectionFailure message to the SLEE 10.

The application will deem the dialogue finished upon receipt of eitherthe Digits Collected message or the Collection Failure message and willproceed to remove the Dialogue Id and to place it back in the list offree Dialogue Id's.

The SLEE's External IP Resource Message Handler 19Hext receives themessage and retrieves the Call Instance 22 by means of the associationwith the Dialogue Id (step 59). The message is then added to the CallInstance's API Events queue as an API IP Resource Message (Msg) event(step 60) and the Call Instance 22 itself is added to the list ofExecutable Calls of the owning Service Instance (step 61). The Scheduler15 is now triggered once again.

When the Scheduler 15 decides that it is the call's turn once more, theAPI IP Resource Msg event, and the message itself, are sent to theapplication (step 62), as shown in FIG. 9.

The application now proceeds to the next following state in the statetable for the service and accesses a database 28 associated with thatapplication type using the collected account number to retrieve a PINstored with the account number and to compare the retrieved PIN with thecollected PIN.

If the PINs match, the application accesses the database again toretrieve the customer style of address and the time (including date)when the last retrieve access was made, and to overwrite that time withthe time of the present retrieval access. The application now sends asecond API Resource command including two fields containing respectivevariable parameters, the first being the customer's address style andthe second being the last retrieval time (including date). Theapplication then sends an API Suspend command and an API ProvideInstruction command and waits for the Scheduler 15 to send it detailsfrom the next selected Call Instance 22.

The SLEE 10 now allocates a new Dialogue ID, by the External IP ResourceHandler 19Hext, and passes this second API Resource command to theResource X in the same way as for the first API Resource command. Onreceipt, the Resource X generates an announcement having a number offixed components and a number of variable components, namely, “Hello”(fixed), “Andy.” (variable, the customer's style of address), “You lastused voicemail at” (fixed), “three thirty pm” (variable), “on the”(fixed), “tenth” (variable), “of” (fixed), “June.”(variable). Thisprovides a measure of security, because if the customer had not accessedvoicemail on that occasion he will now know that someone else was inpossession of his PIN and can take steps to change his PIN.

When the Resource X has finished generating this second announcement itwill send an API IP Resource Message to the SLEE 10 which will enter itin the Call Instance's API Events queue.

When the application next processes this Call Instance it will go to thenext state which is to inform the customer how many voicemail messageshave been deposited in his voicemail store. The application accesses thedatabase to retrieve the number of deposited voicemail messages andsends a third API Resource command including a field containing thisnumber and another field containing the time. Again, the applicationthen sends an API Suspend command and an API Provide Instructioncommand.

The SLEE 10 sends this third command to Resource X, which is stillreserved for this call, by allocating a free Dialogue ID in the samemanner as before.

Resource X responds to this third command by generating an announcementcomprising a plurality of components, two of which are variablecomponents. The first component is “Good”, which is fixed. The secondcomponent is variable and is selected from “Morning”, “Afternoon”, or“Evening” depending upon the value in the time field of the receivedcommand, i.e. the Resource X has three time windows, midnight to midday,midday to 6.00 pm, and 6.00 pm to midnight, and makes the selection bycomparing the time value with the window boundaries to determine theappropriate window and hence the corresponding component. The thirdcomponent is “Welcome to voicemail. You have”, which is fixed. Thefourth component is variable and is selected from a range of words(speech segments) corresponding to the possible number of voicemailmessages in the voicemail message database, in other words, from “no”to, for example, “twenty”. The fifth component is “new”, which is fixed.The sixth component is variable and is selected from “message” or“messages” depending upon whether there is a single voicemail message ora plurality of voicemail messages or no voicemail messages.

In practice, the application will have further stages, e.g. asking thecustomer if he wants to know the names of the people who have depositedvoicemail messages (when depositing a voicemail message they would havebeen asked to state their name), informing the customer of those names(possibly in association with voicemail message numbers), receiving thecustomer's selection and generating the voicemail message (by retrievalfrom the voicemail platform database), asking the customer if he wantsto delete the voicemail message or leave it or archive it, and managingthe voicemail message database in the event that the customer hangs up(terminates his call) during generation of a deposited voicemailmessage. However, the skilled person in the art will understand theoperation of the service node and its SLEE sufficiently without adetailed description of such further stages of the voicemail service.

When the application reaches a final state, e.g. has received from thecustomer a positive indication that he is terminating his access to theservice or has received from the Resource X that a timeout has occurred,then it sends an API Finished signal to the SLEE 10 (step 63). This isreceived by an API Finished Handler 27 of the SLEE 10 which commences toclear down the call.

First, the SLEE 10 must disconnect the speech paths. It allocates a freeSwitch Dialogue to the Call Instance 22 (step 64) and sends a message tothe switch 17 requesting the disconnection of Resource X and the caller(step 65). The switch 17 performs the disconnection (step 66) andreturns a Disconnection Complete message back to the SLEE 10 (step 67).

If Resource X is still in open dialogue with the SLEE 10 then it must becleared down. The SLEE 10 does this as shown in FIG. 10, by firstsending the mapped IP Resource 3 into clearing by moving the mappedresource into the Call Instance's Clearing Resources location (step 68),and then sending a Clear Down message to Resource X (step 69). Theincoming call is cleared in a similar way through the Call Model 14 andthe call is marked as currently being cleared down (step 70).

Resource X receives the message and initiates its clear down procedureas shown in FIG. 11. When it has finished clearing down, it sends aClear Down Complete message to the SLEE 10 (step 71). This message isreceived by the SLEE's External IP Resource Message Handler 19Hext whichretrieves the Call Instance by means of the association with theDialogue Id. This Dialogue Id is removed from the resource and placedback in the Free Dialogue Ids store (step 72). The resource itself ismoved out of the Call Instance 22 and back into the Free Resources store(step 73).

If this was the last resource to clear belonging to the call (i.e. theincoming call has also finished clearing) then the call is complete. TheCharge Record is time stamped and then sent out to the Billing System 18(step 74).

What is claimed is:
 1. A service node for use in an intelligentcommunications network for providing services for customers connectedvia local communication lines to service switching points of theintelligent communications network, said node including therewithin: aservice control point having service defining means and servicecontrolling means; a peripheral platform comprising a plurality of typesof resources, wherein for each said types of resource there being aplurality of resources for performing a particular call processingfunction associated with the respective type of resource, the peripheralplatform being coupled to the service control point via a respectivesignaling link; and, a switch arranged for connection between ones of afirst set of ports and ones of a second set of ports, the switch beingcoupled to the service control point via a respective signaling link,having respective ones of said second set of ports of the switchconnected to said resources, and being arranged to connection at saidfirst set of ports of speech paths of communication lines connected toservice switching points of the intelligent communications network, andwherein the service defining means is arranged to define a plurality ofservices and is operable to generate a reserve resource type request forrequesting reservation of a required type of resource of said pluralityof types of resources upon receipt of call details received from theswitch in respect of an incoming call routed to the switch from aservice switching point, and the service controlling means is arranged(a) to response to the incoming call to place details of the call incorresponding service queues, (b) to pass details of the incoming callto the service defining means from the top of a service queue; (c) torespond to receipt of a said reserve resource type request from theservice defining means by selecting a resource of the required typerequested whose status is free, changing its status to in use, andincluding the identity of the selected resource in the details of thecall, (d) to respond to receipt of a connection request signal from theservice defining means for the selected resource to be connected to thecall by sending to the switch a connection command to connect the callto the respective speech path for the selected resource, (e) to respondto receipt from the service defining means of a command for the requiredtype of resource to perform its respective function by sending to theselected resource a perform function command signal, (f) to respond toreceipt from the service defining means of a command for disassociatingthe service defining means from the call by storing the then currentdetails of the call, (g) to respond to receipt from the service definingmeans of a request for the service defining means to pass to the servicedefining means the call details then at the top of that service queue,and (h) to respond to receipt from a resource of a function finishedsignal by updating the stored details of the corresponding call andpassing the updated details from store to the bottom of thecorresponding service queue.
 2. A service node as in claim 1, whereinthe service controlling means comprises a common resource handler havinga first part arranged to: respond to receipt of the reserve resourcetype request signal to perform the selection of the free resource andthe provision of its identity for inclusion in the call details, andprovide for the service defining means a resource reserved signal uponcompletion of the reservation of the free resource.
 3. A service node asin claim 2, wherein the common resource handler also has a second partarranged to: respond to receipt of the perform function command signalby selecting from a plurality of dialogue identities a dialogue identityhaving a free status, changing its status to in use, providing theselected dialogue identity to be included in the details of the call inassociation with the selected resource identity, and sending the performfunction command signal in association with the selected dialogueidentity to the selected resource.
 4. A method of operating a servicenode in an intelligent communications network for providing services forcustomers connected via local communication lines to service switchingpoints of the intelligent communications network, wherein said servicenode includes therewithin: a service control point having servicedefining means and service controlling means; a peripheral platformcomprising a plurality of types of resources, there being, for each ofsaid types of resource, a plurality of resources for performing aparticular call processing function associated with the respective typeof resource, the peripheral platform being coupled to the servicecontrol point via a respective signalling link; and a switch arrangedfor connection between ones of a first set of ports and ones of a secondset of ports, the switch being coupled to the service control point viaa respective signalling link, having respective ones of said second setof ports of the switch connected to said resources, and being arrangedfor connection at said first set of ports of speech paths ofcommunication lines connected to service switching points of theintelligent communications network, said method comprising the steps of:receiving at said switch a call routed to the service node from aservice switching point of the network, identifying by said servicecontrolling means a requested service and placing details of the call ina corresponding service queue; passing details of the call, when havinghighest priority in the service queue, to said service defining meanswhen it is next ready to process a call; generating a reserve resourcetype request for requesting reservation of a free resource of aparticular type; selecting, in response to said reserve resource typerequest, a free one of a plurality of resources of said particular type,each being arranged to respond to receipt of a perform function commandby performing its respective function; changing the status of theselected resource from free to in use, and including the identity of theselected resource in the call details; connecting the selected resourceto the incoming call by said switch in response to a connection commandfrom the service defining means; performing by the selected resource itsrespective call processing function; storing the call details current atthe time of commanding the selected resource and releasing the servicedefining means to process another call; generating by the selectedresource function finished signal and in response updating stored calldetails; <placing updated call details at the bottom of thecorresponding service queue; and maintaining the in use status of theselected resource until the call is terminated or the service definingmeans determines that the selected resource is no longer required.
 5. Amethod as in claim 4, wherein the selection of the free resource and theprovision of its identity for inclusion in the call details areperformed by a first part of a common resource handler of the servicecontrolling means, and including the step of: providing by said firstpart a resource reserved signal for the service defining means uponcompletion of the reservation of the free resource.
 6. A method as inclaim 5, including the steps of: selecting from a plurality of dialogueidentities, by means of a second part of the common resource handler inresponse to receipt of the perform function command, a dialogue identityhaving a free status, changing its status to in use, providing theselected dialogue identity to be included in the details of the call inassociation with the selected resource identity, and sending the performfunction command in association with the selected dialogue identity tothe selected resource.